The Multi-Protocol Label Switching (MPLS) protocol is used to forward data in a network based on labels that are attached to each packets. A Label Switched Path (LSP) is comprised of a set of labels which are assigned at each hop of the path. Service providers employ a variety of types of tunnels, such as Point-to-Point, Point-to-Multipoint, and Multipoint-to-Multipoint LSPs, depending on the type of traffic to be carried. A Point-to-Multipoint (P2MP) LSP is most suitable for multicast services, such as Internet Protocol Television (IPTV), Content Delivery Networks, etc.
A P2MP LSP has a root node and multiple leaf nodes, and one or more branch node along the path from root node to leaf nodes, see FIG. 1 for a diagram of an exemplary MPLS network. At a branch node, one incoming packet can be replicated on multiple outgoing interfaces, each replication having a unique label.
An LSP can be established statically by the configuration of management layers, or dynamically by signaling protocols.
Label Distribution Protocol (LDP) extensions for Point-to-Point and Multipoint-to-Multipoint LSPs can be used as a signaling protocol to establish a P2MP LSP. These extensions are referred to as Multicast LDP (mLDP). With mLDP, a leaf node can decide to join or leave a P2MP LSP dynamically based on a trigger detected at the leaf node. However the path from root to leaf will follow the best route as calculated by routing protocols without provisioning Traffic Engineering parameters (e.g. bandwidth reservation).
Extensions to the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) can also be used to establish a P2MP LSP. An advantage of RSVP-TE is that Traffic Engineering parameters can be provisioned along the path, which optimizes network performance and best serves the Quality of Experience requirement of IPTV. A disadvantage of RSVP-TE is that each leaf node requesting to join the P2MP LSP must be explicitly configured at the root node, by the operator or a configuration process, which makes it impossible for leaf nodes to dynamically join (or leave) the P2MP LSP. In one example, if a leaf node is added or removed, the whole LSP tree is recalculated, the old tree is deleted, and the new recalculated tree is signaled to the participating nodes. Such a solution leads to effective bandwidth management and optimizes resource usage in the network, but requires heavy overhead manual configuration in the set-up.
U.S. Pat. No. 7,801,137 to Vasseur et al only partially addresses this problem by allowing a leaf node to determine the root node of a requested multicast group. A request is sent to the root node, using a proprietary protocol, to request a path between the leaf node and a tunnel tree of the multicast group. If such a tunnel tree exists, the root node computes a path to add the leaf node to the tree and sends a reply to add the leaf node to the tree at a selected node of the tree. The leaf node can then be added to the multicast group tunnel tree over the computed path at the selected node.
At present, there is no mechanism supported by an open standard group for dynamically provisioning a RSVP-TE P2MP LSP using standard protocols. Accordingly, it should be readily appreciated that in order to overcome the deficiencies and shortcomings of the existing solutions, it would be advantageous to have a solution for dynamically adding or removing leaf nodes in a P2MP LSP using RSVP-TE.